Providing a software debug capability may be problematic at various phases during the software development life cycle. For example, operating systems may provide source code level debuggers that may be useful for initial design unit level testing on a host system. As the software product progresses through the development process, however, debuggers may not be available for target system testing and/or field testing. Some embedded software systems may not have the support of a software debugger or analyzer. Moreover, certain types of real-time sensitive software routines, such as device drivers, may not be compatible with conventional software debug tools.
One option for collecting debug data when testing high-level software is to call a conventional print function, which is typically provided in most high level programming languages. For example, the C programming language provides the printf( ) library function for writing data to a standard output. Unfortunately, the printf( ) function may be relatively inefficient, as parsing and formatting the arguments to the printf( ) function may be time consuming. As a result, real-time sensitive software routines, such as device drivers, may not be allowed to make printf( ) function calls. Furthermore, the inefficiency of the printf( ) function may alter a test scenario so drastically that it may become invalid.
Another option for collecting debug data is to implement a custom trace. A custom trace typically involves the definition of a set of symbols and the allocation of a trace buffer. The software may then be modified to write specific symbols into the trace buffer when certain portions of code are executed. When a software error occurs, the trace buffer may be read and the symbols stored therein decoded. These symbols may then be used to determine the program flow that led to the error. While a custom trace may be more efficient than calls to a conventional print function, it may be more difficult to implement and maintain.